Skip to content

fix(tui): clear answer editing state when selecting other options - #44240

Open
aniruddhaadak80 wants to merge 2 commits into
anomalyco:devfrom
aniruddhaadak80:question-editing-state
Open

fix(tui): clear answer editing state when selecting other options#44240
aniruddhaadak80 wants to merge 2 commits into
anomalyco:devfrom
aniruddhaadak80:question-editing-state

Conversation

@aniruddhaadak80

@aniruddhaadak80 aniruddhaadak80 commented Aug 22, 2026

Copy link
Copy Markdown

Issue for this PR

Closes #44192

Type of change

  • Bug fix
  • New feature
  • Refactor / code improvement
  • Documentation

What does this PR do?

Mouse handlers call selectOption()/selectTab() directly and bypass the enabled: !store.editing gate on the keybindings. So after selecting "Type your own answer" (editing mode), clicking a preset option (or another question tab) picks it but leaves store.editing stuck on true. At the confirm tab both binding sets then refuse Return - the editing set requires !confirm() and the normal set requires !store.editing - so the answers can never be submitted.

This clears editing when a preset option is picked or the tab changes. Selecting the custom row still enters edit mode as before; keyboard-only flows are unchanged since those keys are already gated off while editing.

How did you verify your code works?

  • Reproduced the flow locally in the TUI: select "Type your own answer", click a preset option, advance to confirm, Enter does nothing before this change and submits after.
  • Keyboard-only flow (escape out of editor, arrows, enter) behaves as before.
  • bun run typecheck clean in packages/tui; existing tui test suite shows no new failures.

Screenshots / recordings

Not a visual UI change.

Checklist

  • I have tested my changes locally
  • I have not included unrelated changes in this PR

@Enough1122

Enough1122 commented Aug 23, 2026

Copy link
Copy Markdown

AI code review — automated review for reference, author can ignore or act on any point.

Correct root-cause analysis: mouse paths call selectOption()/selectTab() directly and bypass the enabled: !store.editing keybinding gate, so editing could stay true and permanently swallow Return on the confirm tab.

Details:

  1. In selectTab (packages/tui/src/routes/session/question.tsx, hunk @@ -100,6, added line 103), consider early-returning when index === store.tab. As written, any click that re-triggers selectTab for the current tab clears editing even when the user is actively typing a custom answer, discarding editor focus/state unintentionally.
  2. In selectOption (hunk @@ -118,6, added line 124), placement looks right — the custom-answer row must still end up with editing: true afterward, which relies on its branch running after this line. A brief comment pointing at that invariant (or an assertion in tests) would prevent future reordering regressions.
  3. No automated coverage was added for the store transition (editing cleared on tab/option change, kept for the custom row). Even a small unit test around these handlers would lock in the fix described in issue TUI: If "Type your own answer" in question/ask prompt was selected and then switched to a different option, the answers cannot be submitted #44192.

@aniruddhaadak80
fix(tui): clear answer editing state when selecting other options
d2b7744
@aniruddhaadak80
fix(tui): keep answer editor open when clicking the active question tab
1d70070 
Review follow-up for anomalyco#44240: selectTab previously reset editing state even
when the clicked tab was already active, so re-clicking the current tab
header closed a custom-answer editor mid-typing. Navigation keybindings are
disabled while editing, so mouse clicks were the only path that could hit
this. Same-tab selection is now a no-op.

Also documents the ordering invariant in selectOption: the custom-answer
branch opens the editor and must return before any unconditional editing
reset.
@aniruddhaadak80

aniruddhaadak80 commented Aug 25, 2026

Copy link
Copy Markdown
Author

Thanks for the review - addressed in 1d70070:

  1. Same-tab guard: added if (index === store.tab) return at the top of selectTab. Verified safe for keyboard paths: left/right/tab bindings live in the enabled: !store.editing context, so they can't fire mid-typing; the wrap-around call with a single question is also unreachable while editing. The only same-tab caller during editing was the mouse click on the active tab header - now a no-op.

  2. Ordering invariant: added a one-line comment in the other() branch of selectOption noting it must return before any unconditional editing reset below it.

  3. Store-transition tests: skipped for now, with reasoning. The handlers are closures inside the route component; the only existing harness that mounts routes (createTestRenderer + full app boot) would require SDK question fixtures plus simulated mouse events - an integration test disproportionate to this fix, and more fragile than the logic it locks in. Happy to extract the tab/option state transitions into an exported pure module if maintainers prefer that seam; held off since it restructures working component internals.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

TUI: If "Type your own answer" in question/ask prompt was selected and then switched to a different option, the answers cannot be submitted

2 participants

@aniruddhaadak80 @Enough1122